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Mobility handling of user equipments in IJRA_PCH state for 

MBMS 



FIELD OF THE INVENTION 
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5 The present invention relates to a method for supporting 
mobility of URAJ?CH UEs with respect to MBMS services. 



BACKGROUND OF THE INVENTION 

The work item Multimedia Broadcast Multicast Service (MBMS) 
10 is currently being standardised for release 6 within 3GPP . 
There are two modes of point-to-multipoint (ptm) operation 
defined, the broadcast and the multicast mode- This 
invention relates to the multicast mode and the notification 
and counting of UEs in URAJPCH state. 

15 The specifications require that it shall be possible for a 
UE that has previously joined an MBMS service to receive 
this service at session start, as long as it remains in the 
multicast area and has sufficient UE capabilities - 



20 



However, in current specifications or discussions on MBMS, 

no mechanism has yet been defined for providing a 

: notification at session start to a UE in URA.PCH state in 

* » m 

: : : case the URA (UTRAN Registration Area) that the UE is 

located in also contains cells that do not belong to the S- 
V": RNC. 
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Furthermore, counting of UEs in URA_PCH state is not clearly 
defined. Since it is possible to count UEs in all other 
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states at session start mechanisms for counting of URA^PCH 
UEs shall also be provided. 



DESCRIPTION OF THE INVENTION 



In case the UE is in URA-JPCH state, current architecture 
assumes that no UE context exists in the drift RNC . It is 
only the Serving RNC that knows where, i.e. in which URA, 
the UE is, 

10 Also it is allowed to have URAs that span over cells that 
belong to different RNCs . In normal operation according to 
the state of the art a UE in URA_PCH state can move around 
between cells that belong to the same URA without indicating 
to the network that it is located in a different cell. It is 

15 only in case it moves into a cell that does not belong to 
' the URA that is currently allocated to this UE that it sends 
a message to the network indicating that it has changed its 
location. This message is the URA UPDATE message. 

The problems could be illustrated with the following 
20 example: Cell 1, 2 and 3 belong to RNC1 ■ Cell 4 and 5 to 
RNC2 . Cell 1, 2, 3 and 4 corresponds to URAl and Cell 3, 4 
and 5 corresponds to URA2 . If a UE starts in Cell2, has RNC1 
as its S-RNC and is moved to URA^PCH state belonging to 
URAl , the UE can move between Cell 1-4 without sending any 
25 message (URA UPDATE) to the network (F2STC1) . However, if it 
moves to Cell5 it will send the URA UPDATE message. 

If now this UE has joined an MBMS service, it needs to get 
the notification of session start and to be counted if it 
remains within the MBMS multi-cast area (it is assumed here 
30 that all cells belong to the multi-cast area.) The counting 
is used by the controlling RNC to decide whether the 
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transmission of MBMS data in a cell shall foe done via point- 
to-point (ptp) or point-to-multipoint {ptm) . 



Three problems can be foreseen: A first problem relates to 
"Missed notification in DRNC" . If the UE moves to Cell4 it 
5 will not send any URA UPDATE message. At the same time if 
R3SJC1 receives a session start it will send a notification of 
this in a broadcast manner on the MCCH in all cells 
belonging to RNC1 . However, since the US is in Cell4 it will 
not receive this notification from RNC1. Also in case there 

10 are no other known {from HNC2s point of view) MBMS UE for 
this MBMS service in Cell4 RNC2 will not send a notification 
in this cell. This because KNC2 has no knowledge about this 
UE that only has a context in KNC1 {which is the SKNC) . 
Therefore there is a risk that Ues in URA_PCH state miss the 

15 notification of an MBMS session, and. fail to receive the 
service . 

A second problem relates to "Failed counting in DRNC" . If 
the UE moves to Cell4 it will not send any URA UPDATE 
message. Also there is no stored UE context for this UE in 
20 RNC2. In the case where session start is however received by 
RNC2 (i.e. due to other joined MBMS UEs) , RISIC2 may initiate 
a counting procedure in order to base its ptm/ptp decision 
on the amount of joined UEs in this cell. Connected, mode UEs 
are counted by counting the MBMS UE contexts stored for the 
: : : 2 5 UEs that are located in this cell. Idle mode UEs are counted 
: with a counting procedure where a certain fraction send a 

:T; * RRC C03SSNECTION REQUEST message and transit to rrc connected 

fV- raode. If the number of UEs is high enough in this cell, ptm 

: \: transmission is used. However, the UE that moved to Cell4 in 

3 0 URA_PCH state will not be counted with any of these existing 
methods. RNC2 has no context for this UE and the UE will not 
respond to the idle mode counting. Therefore there is a risk 

* « • 
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that an erroneous ptp to ptm decision is taken in RNC2 for 
Cell4, leading to waste of radio resources. 

A third problem relates to "Paging load". As previously 
stated, UEs in URA^PCH state shall be notified of the 
5 session start. In case lur linking is not performed, 
notification shall necessarily be performed by BNCl via 
dedicated paging (i.e. on DCCH) , as RNC2 has no knowledge of 
URA_PCH UEs for which it is not the serving RNC. However, it 
is foreseeable that dedicated paging would entail heavy load 
10 on the lur and Uu interfaces. In case of overload, paging 
messages could be lost/discarded in the network, thus 
leading the UE in URA_PCH state to miss the notification. 

t 

The following describes the basic concept of the present 
invention: In order for URAJPCH UEs to be alerted of session 
15 start when moving into a CRNC/DRMC area, an lur linking 
procedure is introduced, initiated by the serving RNC. This 

• » 

procedure provides all necessary MBMS information to the 
CRNC/DRNC (note that in the remaining of this document, the 
KNC (different from SRNC) controlling the cell in which the 
20 UK in URA_PCH state is located is referred as CRNC/DRNC) . 
Furthermore, several procedures enabling the CRNC/DKNC to 
perform counting of UEs in URA_PCH state are described, each 
. t • ■ mechanism being optimized for a given amount of UEs to be 

counted. 
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in the proposed scheme, the SRNC shall transmit an MEMS 
ATTACH REQUEST message, e.g. as to be described in RNSAP 
specification 25.423, to all drift BWCs controlling at least 
one cell ■ in the URA entered by the UE, either upon receipt 
of URA UPDATE, e.g. as described in 25.331, (new URA) from 
the UE, or at transition to URA_PCH state from any other UE 
RRC state (early linking) , or upon receipt of SESSION START 

(as to be described in RftNAP specification 25,413} (late 

linking) . 

The SRNC shall include following information in the MBMS 
ATTACH REQUEST message: 



• Joined MBMS services ID 



• URA ID 

• U-RNTI, IMSI, UTRAN DRX Cycle Length 

15 Upon receipt of MBMS ATTACH REQUEST message for a UE in 
URA_PCH state, the CKNC/DRNC shall: 

• create an MBMS US context, and store 
information included in the received 
message into this context 
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(if needed) create an MBMS service 
context and register towards the 
upstream 3GSN. The MBMS service ID 
and the U-KNTI shall be included in 
this context . 
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This will make it possible for the CRNC/DRNC to notify the 
UE in URA_J?CH state about the MBMS session start and 
provides a solution to the first and third problem. 

Note that the SRNC would be responsible for updating the 
MBMS UE context whenever the URA.PCH UE would move to a new 
URA (3GPP TS 25-346 MBMS ATTACH REQUEST) . 

Furthermore, the MBMS UE context (and possibly the MBMS 
service context, in case no RRC connected UEs joined to the 
MBMS service remain in the RNC area) would be deleted in the 
CRNC/DRNC whenever the URA_J?Ch' UE would move to a URA 
entirely comprised in another RNC area. In this case, the 
SRNC would transmit TS 25.346 MBMS DETACH REQUEST to the 
CRNC/DRNC . 



Also at session start, the CRNC/DRNC may decide to perform 
15 counting of URA__PCH UEs, i.e. to find out the exact location 
of such UEs (on a cell level) - This is facilitated due to 
the contexts created for URA_PCH UEs in the CRNC/DRNC. 

Several applicable strategies may be used by the CRNC/DRNC 
(note that in all these strategies, CELL, UPDATE and CELL 
20 UPDATE CONFIRM messages are used, but it could as well be 
, any other UE uplink message, e.g. a specific MBMS message.) 



25 
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a) The CRNC/DRNC pages the URA. JPCH UEs individually, 
utilizing the information stored in the MBMS UE context 

(one for each UE) . Upon receipt of the paging message, 
the URA„PCH UE shall respond with a CELL UPDATE 
message indicating either a special cause value e.g. 

"respond to MBMS counting" (assuming the UE can link 
paging to MBMS notification) or any of the existing 

cause values, e.g. "paging response". Both alternatives 

could be seen as equally useful. 
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in this case, it is foreseen that the SRNC would send 
back the UE to URA_PCH; however, the CRNC/DRNC would 
now have the information in which cell the UE is 
located. Even though this information may quickly 
become out of date, it is however assumed that this 
procedure would provide reliable input for counting 
purpose. Note that this procedure is mainly applicable 
when the amount of URA_PCH UEs is kept low. 



10 
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b) The CRNC/DRNC includes »URA_PCH specific paging 
information" in the MBMS NOTIFICATION message 
broadcasted on MCCH. Indeed, UEs in URA_PCH state are 
notified of incoming MBMS calls either on MICH (no ptm 
session ongoing) or get notified on MTCH (ongoing ptm 
session) , after which they are mandated to read the 
MCCH. The "URAJPCH specific paging information" would 
include a probability factor: by drawing a random 
number and using the received probability factor, the 
UE may decide to transmit a CELL UPDATE to the 
CRNC/DRNC (with a specific MBMS cause value, eg. "MBMS 
counting") . The "URA_PCH specific paging information" 
could either be related to URAJPCH mobiles only, the 
information sent to idle mode UEs could be used as well 
for URA_PCH UEs. 



«. ... 
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Note that the UE would stay in URA_PCH state during 
this procedure, and as a consequence the CRNC/DRNC 
would not forward the message to the SRNC . Instead, the 
procedure would be terminated, and no CELL UPDATE 
CONFIRM would be sent back to the UE- Again, it is 
assumed that this procedure would provide reliable 
input for counting purpose, even though the location 
information may quickly be out of date. Also since the 
CELL UPDATE message is sent in unacknowledged mode some 
of these messages will be lost and the UE will not re- 
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send the message after a certain time. This procedure 
is applicable irrespective of the amount of URA_PCH UEs 
to he counted, however, it is assumed that it would be 
used when the number of UKA_PCH UEs is neither too low, 
noar too high. 

c) This is very similar to (a) and the CBNC/DSNC pages the 
URA.PCH UEs individually as in (a) , and the UE responds 
with a CELL UPDATE message as in (a) . However, the 
individual page message includes a special cause value 
e.g. "MBMS counting" so that the UE khows that this 
page is only done for counting. 
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However, instead of sending the CELL UPDATE message to 
the SRNC as in (a) the UE transits directly hack to 
URA_PCH state as in (b) . Also the same inaccuracy due 
to mobility and lost CELL UPDATE messages as mentioned 
in (b) would also apply here. Note that this procedure 
is mainly applicable when the amount of URA_PCH UEs is 
kept low . 
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d) The DRNC applies a homogeneous probability factor for 
the UE in each cell. For instance, if the URA comprises 
N cells, a URA_PCH UE could be counted as 1/N in each 
cell. This method is obviously applicable when the 
number of UES in URA_PCH state is large, thus allowing 
statistical averaging over all cells. Several other 
functions as compared to 1/N could be used, e.g. taking 
into account the cell where the UE did its last uplink 
message, and the time since when this was done, etc. 



m a m 



A combination of measures (a) to (d) , or (a) to (d) on their 
own, provides solutions to the second problem. 



